Looking for guidance on how the pattern for checking for the feature should be implemented in this context

Aside from the one logic test I pointed out, yes, I think this looks like the way to go.
So:

1. There are 4 parser backends (Byte-based, Reader-based, DataInput-backed, Async/Non-blocking
2. Need unit tests for all 4 backends, but can be simple.

One big question is this: should RS be allowed only as white-space, or also in Content?
I think former would be easier, latter little bit more work. But I guess latter is not all that much work.
But maybe start with former, and make description say that it is allowed for ignorable whitespace between tokens. If support for in-content values (as escaped) is needed, can add separate feature.

On converting to TAB -- if only used for ignorable whitespace, no need to do anything: conceptually can be thought of working like TAB of course, but ignorable whitespace is not reported in any way.
But even in "allow in content" case, I'd vote for keeping it as-is with no conversion.

I pushed some minor wording changes, addition of @since annotations in Javadocs.

Quick note: since 2.17.0 was released, can no longer be merged into 2.17 branch: API changes need to go in new minor releases. So needs rebasing to 2.18.

#633 was implemented by alternate PR, #1414; included in 2.19.0. Closing.